Vems:  A  Tool  for  Quantitative  Analysis  of 
Finite-State  Real-Time  Systems 


S.  Campos  E.  Clarke  W.  Marrero  M.  Minea 
August  12,  1996 
CMU-CS-96-159 


School  of  Computer  Science 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


Revised  version  of  the  paper  appearing  in  the  proceedings  of  the  ACM  Workshop  on  Languages,  Compilers 
and  Tools  for  Real-Time  Systems,  La  Jolla,  CA,  June  1995 


Abstract 

Symbolic  model  checking  is  a  technique  for  verifying  hnite-state  concurrent  systems  that  has  been  extended  to  handle 
real-time  systems.  Models  with  up  to  10^°  states  can  often  be  verihed  in  minutes.  In  this  paper,  we  present  a  new  tool 
to  analyze  real-time  systems,  based  on  this  technique.  We  have  designed  a  language,  called  Verus,  for  the  description  of 
real-time  systems.  Such  a  description  is  compiled  into  a  state-transition  graph  and  represented  symbolically  using  binary 
decision  diagrams.  We  have  developed  new  algorithms  for  exploring  the  state  space  and  computing  quantitative  information 
about  the  system.  In  addition  to  determining  the  exact  bounds  on  the  delay  between  two  specihed  events,  we  compute 
the  number  of  occurrences  of  an  event  in  all  such  intervals.  This  technique  allows  us  to  determine  performance  measures 
such  as  schedulability,  response  time,  and  system  load.  Our  algorithms  produce  more  detailed  information  than  traditional 
methods.  This  information  leads  to  a  better  understanding  of  the  behavior  of  the  system,  in  addition  to  verifying  if  its  timing 
requirements  are  satisfied.  We  integrate  these  ideas  into  the  Verus  tool,  currently  under  development.  To  demonstrate  how 
our  technique  works,  we  have  verihed  a  robotics  control  system.  The  results  obtained  demonstrate  that  our  method  can  be 
successfully  applied  in  the  analysis  of  real-time  system  designs. 
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1  Introduction 


Model  checking  is  a  technique  for  specifying  and  verifying  finite-state  concurrent  systems  [4,  5].  It  determines 
automatically  if  a  system  satisfies  its  specifications.  Models  with  up  to  10^**  states  can  often  he  verified  in  minutes 
by  using  symbolic  techniques  [2,  11].  The  method  has  been  used  successfully  to  verify  a  number  of  real-world 
applications.  For  example,  it  has  been  used  to  find  errors  in  the  Futurebus-i-  cache  coherence  protocol,  adopted 
as  a  standard  by  both  IEEE  and  the  U.S.Navy  [6]. 

Many  real-time  systems  can  be  represented  by  finite-state  models.  In  [3]  we  have  shown  how  to  apply  symbolic 
model  checking  techniques  to  analyze  finite-state  real-time  systems.  The  method  presented  in  that  paper  differs 
significantly  from  other  verification  methods.  It  computes  quantitative  timing  information  about  a  model  rather 
than  just  determining  whether  it  satisfies  a  given  specification  or  not.  The  algorithms  therein  provide  insight  into 
how  well  a  system  works,  in  addition  to  determining  its  temporal  correctness. 

In  this  paper,  we  extend  our  technique  in  two  ways.  Variations  of  the  previously  described  algorithms  are 
discussed.  The  original  algorithms  compute  the  exact  lower  and  upper  bounds  on  the  amount  of  time  that  elapses 
between  two  events.  Alternatively,  we  may  be  interested  not  only  in  the  length  of  the  time  interval  between 
two  events,  but  also  in  the  number  of  times  a  third  event  occurs  within  such  an  interval.  Eor  example,  priority 
inversion  time  may  be  determined  by  computing  the  number  of  time  steps  executed  at  lower  priority  levels  from 
the  moment  a  high  priority  process  requests  execution  until  it  has  finished.  We  describe  in  detail  algorithms 
to  compute  such  information.  The  addition  of  these  algorithms  increases  the  power  and  applicability  of  our 
technique. 

We  also  extend  our  previous  work  by  defining  a  new  language,  Verus,  for  describing  real-time  systems.  This 
language  has  been  specifically  tailored  to  simplify  the  expression  of  real-time  properties  and  constraints.  Verus 
provides  special  primitives  to  express  timing  aspects  such  as  deadlines,  priorities  and  delays.  Nondeterminism  is 
also  supported,  which  allows  partial  specifications  to  be  described.  The  syntax  of  Verus  resembles  the  C  language 
syntax,  since  we  believe  that  the  familiarity  with  a  well  known  language  will  enable  non-experts  to  use  the  new 
tool  more  efficiently. 

Einally,  we  integrate  all  these  ideas  into  a  tool  for  the  analysis  and  verification  of  real-time  systems,  the  Verus 
tool,  currently  under  development.  The  real-time  application  being  analyzed  is  described  in  the  Verus  language. 
This  description  is  then  compiled  into  a  labeled  state-transition  graph  that  formally  models  the  behavior  of  the 
system.  The  quantitative  algorithms  described  above  can  be  used  to  analyze  its  behavior.  Moreover,  a  CTE 
symbolic  model  checker  [11]  is  implemented  to  augment  the  power  of  the  tool.  This  model  checker  has  been 
extended  to  handle  the  RTCTE  logic  [7],  allowing  the  expression  of  time  bounded  properties. 

To  demonstrate  how  our  tools  work,  we  verify  a  robotics  example  derived  from  [10].  The  robot  we  describe 
is  used  in  nuclear  reactors  to  measure  the  shapes  of  pipes  by  moving  around  them  with  a  distance  sensor.  Its 
controller  consists  of  a  set  of  periodic  processes  that  control  each  subsystem  of  the  robot.  We  model  this 
controller,  and  use  the  algorithms  described  in  this  paper  to  gather  timing  information  about  it.  We  determine 
the  schedulability  of  the  system  using  this  data.  Moreover,  the  type  of  information  computed  by  our  algorithms 
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allows  us  to  identify  inefficiencies,  to  suggest  optimizations  to  the  design,  and  to  analyze  the  performance  of 
these  proposed  changes. 

Several  other  methods  for  analyzing  real-time  systems  exist.  The  rate  monotonic  scheduling  theory  (RMS)  [13, 
10]  proposes  a  schedulahility  test  based  on  total  CPU  utilization.  However,  there  are  a  number  of  limitations  on  the 
type  of  processes  that  can  be  analyzed  by  this  method,  including  restrictions  on  periodicity  and  synchronization. 
Another  approach  to  schedulahility  analysis  uses  algorithms  for  computing  the  set  of  reachable  states  of  a  finite- 
state  system  [8,  9].  No  restrictions  are  imposed  on  the  model  but  the  algorithm  only  checks  if  exceptions  can 
occur  or  not,  and  other  types  of  properties  can  only  be  verified  if  encoded  as  exceptions.  A  symbolic  model 
checker  for  real-time  systems  is  proposed  in  [14].  However,  in  this  approach  quantitative  information  is  not 
generated,  and  the  verifier  only  determines  if  the  model  satisfies  a  given  property  or  not. 

By  contrast,  our  analysis  method  only  requires  that  the  model  be  finite-state.  Moreover,  our  algorithms  provide 
valuable  timing  information  about  the  system,  as  opposed  to  only  determining  if  it  satisfies  a  given  property. 
This  can  lead  to  a  better  understanding  of  system  behavior  and  can  be  essential  in  improving  performance. 

The  remainder  of  the  paper  is  organized  as  follows.  The  next  section  discusses  the  Verus  language.  In 
Section  3  the  symbolic  algorithms  for  computing  the  longest  and  shortest  paths  between  two  state  sets  are 
presented.  Symbolic  algorithms  for  counting  the  number  of  states  that  satisfy  a  given  condition  along  a  path 
between  two  sets  of  states  are  described  in  section  4.  Section  5  discusses  the  robotics  example  and  shows  how  it 
can  be  analyzed  using  our  techniques.  Section  6  concludes  the  paper  with  directions  for  future  work. 

2  The  Verus  Language 

Verus  is  the  language  we  use  to  specify  the  real-time  systems  to  be  verified.  It  is  an  imperative  language  with  a 
syntax  resembling  that  of  the  C  language.  Special  primitives  are  provided  for  the  expression  of  timing  aspects 
such  as  deadlines,  priorities,  and  time  delays.  The  data  types  allowed  are  integer  and  boolean.  Nondeterminism 
is  supported,  which  allows  partial  specifications  to  be  described.  The  language  constructs  have  been  kept  simple, 
making  an  efficient  compilation  into  a  state-transition  graph  possible.  This  also  allows  the  user  to  express  the 
desired  features  precisely,  and  thus  to  optimize  the  code.  Smaller  representations  can  then  be  generated,  which 
in  our  experience  is  critical  to  the  efficiency  of  the  verification  and  permits  larger  examples  to  be  handled. 

We  briefly  describe  the  syntax  of  the  Verus  language  using  as  an  example  part  of  the  code  for  the  robot 
model  analyzed  in  this  paper.  Periodic  execution  is  described  in  Verus  by  the  periodic  statement,  which  has 
three  parameters  followed  by  the  code  that  will  be  executed  periodically.  The  first  parameter  is  the  start  Jime, 
which  specifies  the  number  of  time  units  before  the  first  execution  of  the  periodic  code.  In  this  example  it  starts 
immediately.  The  second  parameter  is  the  period',  in  this  case  the  statements  following  periodic  execute 
once  every  40  time  units.  The  last  parameter  defines  a  deadline  for  the  code.  It  specifies  that  the  code  must  finish 
execution  in  at  most  40  time  units  or  an  exception  is  raised.  Deadlines  can  also  be  defined  in  a  similar  manner 
without  forcing  the  process  to  execute  periodically  by  using  the  primitive  deadline. 

Passage  of  time  is  controlled  by  the  wait  statement.  For  example,  in  line  12  the  motor_control  task 
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1  motor_control ( ) 

2  { 

3  boolean  start,  finish; 

4 

5  periodic(0,  40,  40)  { 

6  start  =  1; 

7  priority ( 1 0 ) { 

8  data_in  =  dev_ready  &  ! abort; 

9  wait ( 1 ) ; 

10  }; 

1 1  priority ( 7 ) { 

12  wait ( 5 ) ; 

13  data_out  =  data_in  &  ! abort; 

14  }; 

15  finish  =  1; 

16  }; 

17  } 

Figure  1 :  The  motor  control  task 

waits  for  5  time  units  before  resuming  execution.  Unlike  regular  imperative  languages,  in  Verus  time  passes 
only  on  wait  statements.  This  feature  allows  a  more  accurate  control  of  time,  and  eliminates  the  possibility  of 
implicit  delays  influencing  the  verification  results.  It  also  generates  models  with  less  states,  since  consecutive 
statements  not  separated  by  a  wait  statement  are  compiled  into  a  single  change  of  state.  Notice  that  this  feature 
affects  the  behavior  of  the  program  significantly.  For  example,  in  general,  a  block  of  code  not  containing  the 
wait  statement  executes  atomically. 

The  select  statement  (not  used  in  the  sample  code)  is  used  to  introduce  nondeterministic  choice  into  a 
program.  If,  for  example,  motor.control  were  allowed  not  to  signal  end  of  execution,  we  could  replace 
line  15  with  finish  =  select  {  0 ,  1 }; .  In  this  case,  the  value  of  finish  after  executing  select  can 
be  either  0  or  1.  These  choices  indicate  that  motor_control  may  signal  termination,  but  does  not  have  to  do 
so.  In  this  way  we  can  model  both  possibilities  without  having  to  specify  all  the  details  that  are  actually  needed 
to  decide  between  these  two  options.  Besides  hiding  unnecessary  details,  nondeterminism  can  be  used  to  verify 
partial  specifications.  Whenever  the  value  of  a  variable  hasn’t  been  determined  in  the  design,  nondeterminism 
can  be  used  to  specify  all  possible  values  the  variable  could  take.  This  approximates  the  behavior  of  the  actual 
system  by  exploring  all  possibilities.  As  the  design  process  evolves,  the  values  can  be  restricted  until  the  correct 
behavior  is  determined.  Nondeterminism  encourages  the  use  of  automated  verification  in  earlier  phases  of  the 
design.  Components  of  the  system  can  be  validated  before  all  modules  have  been  specified.  In  this  way  errors 
can  be  uncovered  before  they  propagate  to  components  added  later  in  the  design. 


3  Minimum  and  Maximum  Delay  Algorithms 

This  section  presents  algorithms  for  computing  minimum  and  maximum  time  delays  between  specified  events. 
We  first  describe  how  a  state-transition  graph  can  be  used  to  model  the  real-time  system  being  verified.  A  state 
V  in  this  model  is  represented  by  a  vector  assigning  values  to  the  state  variables  vi,V2,...,  Vn-  The  transition 
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relation  N  {v,  v')  evaluates  to  true  when  there  is  a  transition  in  the  model  from  the  state  v  to  the  state  v',  where 
V  =  (ui, . . . ,  Vn)  and  v'  =  . . . ,  A  path  in  the  transition  graph  is  defined  as  a  sequence  of  states 

W,  W 5 1^5  •  •  •  such  that  N  (u7,  ui+l)  is  true  for  every  i  >  0.  All  computations  are  performed  on  states  reachable 
from  a  predefined  set  of  initial  states. 

The  algorithms  descrihed  in  this  work  are  implemented  using  symbolic  model  checking  techniques  [2].  Boolean 
formulas  can  he  constructed  from  the  propositional  variables  of  the  model.  A  formula  is  said  to  be  satisfied  in 
a  state  if  and  only  if  the  assignment  of  variable  values  in  the  state  to  the  corresponding  variables  in  the  formula 
makes  it  true.  In  general,  a  formula  can  be  satisfied  in  many  states,  and  we  identify  a  formula  with  the  set  of 
states  that  satisfy  it.  The  transition  relation  can  also  be  represented  by  a  boolean  formula  constructed  from  two 
copies  of  the  propositional  variables  one  for  the  current  state  and  one  for  the  next  state.  There  is  a  transition 
from  state  v  to  state  v'  if  the  assignment  of  the  variable  values  in  state  v  to  the  current  state  variables,  and  the 
assignment  of  variable  values  in  state  v'  to  the  next  state  variables  satisfy  the  formula. 

Our  algorithms  work  on  boolean  formulas  representing  sets  of  states.  For  example,  the  formula  representing 
T{S)  =  {s'  I  (s,  s')  holds  for  some  s  G  S'},  the  set  of  all  successors  of  states  in  a  state  set  S,  can  be  easily 
constructed  from  the  formula  for  S  and  the  formula  for  the  transition  relation  in  one  step,  regardless  of  the 
number  of  states  in  S  and  T{S).  The  fact  that  all  operations  consider  sets  of  states  instead  of  individual  states 
is  one  of  the  main  reasons  for  the  efficiency  of  our  method.  Moreover,  boolean  formulas  are  implemented  by 
binary  decision  diagrams  (BDDs)  [1],  enabling  the  use  of  efficient  algorithms  for  their  manipulation  [2]. 

We  consider  the  minimum  delay  algorithm  first  (figure  2).  The  algorithm  takes  two  sets  of  states  as  input, 
start  wA  final.  It  returns  the  length  of  (i.e.  number  of  edges  in)  a  shortest  path  from  a  state  in  start  to  a  state  in 
final.  If  no  such  path  exists,  the  algorithm  returns  infinity.  Recall  that  the  function  T{S)  gives  the  set  of  states 
that  are  successors  of  some  state  in  S.  The  function  T,  the  state  sets  R  and  R',  and  the  operations  of  intersection 
and  union  can  all  be  easily  implemented  using  BDDs. 


proc  minimum  {start,  final) 

i  =  0; 

R  =starf, 

R'  =  T{R)  U  R\ 

while  {R'  /  i?  A  i?  n  final  =  0)  do 

i  i  +  1; 

R  =  R'; 

R'  =  T{R')  U  R'-, 
if  (i?  n  final  /  0) 

then  return  i; 
else  return  oo; 


proc  maximum  {start,  final) 

i  =  0; 

R  =TRUE- 
R'  =not-final', 

while  {R'  R  A  R'  n  start  /  0)  do 
i  i  +  1; 

R  =  R'; 

R'  =  T~^{R')  n  not. final', 
if  {R  =  R') 

then  return  oo; 
else  return  i; 


Figure  2:  Minimum  and  Maximum  Delay  Algorithms 


The  first  algorithm  is  relatively  straightforward.  Intuitively,  the  loop  in  the  algorithm  computes  the  set  of  states 
that  are  reachable  from  start.  If  at  any  point,  we  encounter  a  state  satisfying^naZ,  we  return  the  number  of  steps 
taken  to  reach  that  state. 

Next,  we  consider  the  maximum  delay  algorithm.  This  algorithm  also  takes  start  and  final  as  input.  It  returns 
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the  length  of  a  longest  path  from  a  state  in  start  to  a  state  in  final.  If  there  exists  an  infinite  path  beginning  in  a 
state  in  start  that  never  reaches  a  state  in  final,  the  algorithm  returns  infinity.  The  function  gives  the  set 

of  states  that  are  predecessors  of  some  state  in  S'  (i.e.  =  {s  \  N{s,  s')  holds  for  some  s'  G  S''}).  We 

also  denote  hy  not -final  the  set  of  all  states  that  are  not  in  final.  As  before,  the  algorithm  is  implemented  using 
BDDs,  however,  a  backward  search  is  required  in  this  case. 

4  Condition  Counting  Algorithms 

In  many  situations  we  are  interested  not  only  in  the  length  of  a  path  from  a  set  of  starting  states  to  a  set  of  final 
states,  but  also  in  measures  that  depend  on  the  number  of  states  on  the  path  that  satisfy  a  given  condition.  For 
example,  we  may  wish  to  determine  the  minimum  (maximum)  number  of  times  a  given  condition  holds  on  any 
path  from  starting  to  final  states. 

Both  algorithms  in  this  section  take  as  input  three  sets  of  states:  start,  cond  and  final.  The  algorithms  compute 
the  minimum  and  the  maximum  number  of  states  that  belong  to  cond,  over  all  finite  paths  that  begin  with  a  state 
in  start  and  terminate  upon  reaching  ^na/. 

To  guarantee  that  the  minimum  (maximum)  is  well-defined,  we  assume  that  any  path  beginning  in  start  must 
reach  a  state  in  final  in  a  finite  number  of  steps.  This  can  be  checked  using  the  maximum  delay  algorithm 
described  in  the  previous  section.  Finally,  we  ensure  that  all  computations  involve  only  reachable  states,  by 
intersecting  start  with  the  set  of  reachable  states  computed  a  priori. 

To  keep  track  at  each  step  of  the  number  of  states  in  cond  that  have  been  traversed,  we  define  a  new  state- 
fransition  system,  in  which  the  states  are  pairs  consisting  of  a  state  in  the  original  system  and  a  positive  integer. 
Thus,  if  the  original  state-transition  graph  has  state  set  S,  then  the  augmented  state  set  will  be  S'a  =  S'  X  IN. 

If  N  C  S  X  S  is  the  transition  relation  for  the  original  state-transition  graph,  we  define  the  augmented  transition 
relation  Na  C  Sa  X  Sa  as 

Na{{s,  k),  {s',  k'))  =  N  (s,  s')  A  (s'  G  cond  AA;'  =  A;-|-1Vs'^  cond  A  k'  =  k) 

In  other  words,  there  will  be  a  transition  from  (s,  k)  to  (s',  k')  in  the  augmented  transition  relation  Na  iff  there  is 
a  transition  from  s  to  s'  in  the  original  transition  relation  N  and  either  s'  G  cond  and  k'  =  k  +  iov  s'  ^  cond  and 
k'  =  k.  We  also  define  T  to  be  the  function  that  for  a  given  set  U  C  Sa  returns  the  set  of  successors  of  all  states 
inU.  More  formally,  r(t/)  =  {u'  \  Na{u,u')  holds  for  some  m  G  t/}.  In  the  actual  BDD-based  implementation, 
an  initial  bound  k^ax  can  be  selected  to  achieve  a  finite  representation  for  k,  and  new  BDD  variables  can  be 
added  dynamically  if  this  bound  is  exceeded.  The  system  is  still  finite-state  because  all  paths  we  consider  are 
finite  and  k  is  bounded  by  their  maximum  length. 

The  algorithm  for  computing  the  minimum  count  is  given  in  figure  3.  In  the  algorithm  text.  Final  and  Not -final 
denote  the  sets  of  states  in  final  and  S  —  final,  paired  with  all  possible  values  of  k.  More  formally: 

Final  =  {(s,  A;)  |  s  G  final,  A;  G  IN}  and  Not-final  =  {(s,  A;)  |  s  ^  final,  k  G  IN} 

The  algorithm  uses  R  to  represent  the  state  set  in  Sa  reached  at  the  current  iteration,  while  Reached-final  and 
R'  are  its  intersections  with  Final  and  Not-final  respectively.  Variable  current -min  denotes  the  minimum  count 
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proc  mincount  {start,  cond,  final) 
current  jnin  —  oo; 

R  =  {(Js,  1)  I  s  G  start  fl  cond}  U  {(s,  0)  |  s  G  start  fl  cond}', 

loop 

Reached-final  =  Rf]  Final', 
if  Reached.final  /  0  then 

m  =  min{A;  |  (s,  k)  G  Reached  -final}', 

if  m  <  current-min  then  current-min  =  m; 

R'  =  Rf]  Not -final', 

if  i?'  =  0  then  return  current  jnin', 

R  =  T{R'); 
endloop; 

Figure  3:  Minimum  Condition  Count  Algorithm 

for  all  previous  iterations.  The  computation  of  the  minimum  value  of  A;  in  a  set  of  pairs  (s,  k)  can  he  done 
hy  existentially  quantifying  the  state  variables  (computing  K  =  {k  \  3(s,  k)  G  S'})  and  following  the  leftmost 
nonzero  branch  in  the  resulting  BDD,  provided  an  appropriate  variable  ordering  is  used. 

At  iteration  i,  the  algorithm  considers  the  endpoints  of  paths  with  i  states.  The  reached  states  that  belong  to 
final  are  terminal  states  on  paths  that  we  need  to  consider.  The  minimum  count  for  these  paths  is  computed,  using 
the  counter  component  of  the  path  endpoints,  and  the  current  value  of  the  minimum  is  updated  if  necessary.  For 
the  reached  states  that  do  not  belong  to  final,  we  continue  the  loop  after  computing  their  successors.  If  all  reached 
states  are  in  final,  there  are  no  further  paths  to  consider  and  the  algorithm  returns  the  computed  minimum. 

Finally,  we  note  that  the  algorithm  for  the  maximum  count  has  the  same  structure  and  can  be  obtained  by 
replacing  min  with  max  and  reversing  the  inequalities.  Variants  of  both  algorithms  can  be  used  to  compute  other 
measures  that  are  a  function  of  the  number  of  states  on  a  path  that  satisfy  a  given  condition.  For  example,  we 
can  determine  the  minimum  and  the  maximum  number  of  states  belonging  to  a  given  set  cond  over  all  paths  of  a 
certain  length  I  in  the  state  space. 

5  A  Robotics  System 

One  application  of  real-time  systems  that  is  becoming  increasingly  common  is  in  robotic  systems.  Guaranteeing 
that  tasks  are  executed  within  their  expected  deadline  is  critical  for  the  integrity  of  a  robot  and  for  the  success  of 
its  mission.  We  show  how  the  computation  of  quantitative  properties  can  assist  in  validating  such  systems.  The 
example  discussed  in  this  section  is  derived  from  the  one  in  [10].  It  describes  a  real  robot  used  in  nuclear  reactors 
to  measure  the  shapes  of  pipes  by  moving  around  them  with  a  distance  sensor.  The  robot  architecture  has  three 
subsystems,  motor,  measurement  and  command  (figure  4).  The  motor  subsystem  controls  the  robot  movements 
and  position.  The  function  of  the  measurement  subsystem  is  to  activate  and  control  the  distance  sensors.  Finally, 
the  command  subsystem  is  responsible  for  receiving  commands  from  the  communication  link  and  sending  those 
commands  to  the  appropriate  tasks. 

Each  subsystem  consists  of  a  set  of  tasks.  The  motor  subsystem  contains  one  task,  motor.control.  Its 


6 


control  flow 


Figure  4:  Robot  Architecture 

function  is  to  receive  data  from  sensors  in  the  servo  motors,  and  actuate  them.  The  task  consists  of  two  subtasks, 
servo_read  and  servo_control.  The  first  one  is  an  interrupt  routine  that  reads  data  directly  from  the 
physical  devices.  The  second  one  processes  this  data  and  outputs  control  signals  to  the  motors  at  a  lower 
priority.  The  measurement  subsystem  has  two  tasks,  sensor_read  and  sensor_control.  The  first  task 
reads  data  from  the  distance  sensors  and  preprocesses  it.  This  information  is  then  sent  to  sensor_control, 
which  processes  it  further  and  outputs  the  results  to  a  remote  system  to  be  analyzed.  Finally,  the  command 
subsystem  also  has  two  tasks.  The  command-read  task  receives  commands  from  the  communication  link  and 
interprets  them.  It  consists  of  two  subtasks:  an  interrupt  routine,  followed  by  a  second  subtask  of  lower  priority. 
The  final  task  of  this  subsystem  is  command-process.  Its  first  subtask  receives  the  command  interpreted  by 
command-read,  and  the  second  one  then  executes  the  command.  Control  variables  that  are  updated  by  this 
subtask  are  used  to  communicate  commands  to  all  other  subsystems. 

All  tasks  are  periodic,  and  their  timing  requirements  reflect  the  characteristics  of  the  environment  in  which 
the  robot  works  and  the  robot’s  expected  response  time.  These  requirements  are  summarized  in  table  1 .  Each 
task  is  presented  as  a  sequence  of  components,  each  with  a  different  execution  time  and  priority.  A  component 
may  correspond  to  a  subtask,  or  subtasks  may  be  split  in  more  than  one  component  due  to  synchronization.  For 
example,  the  first  components  of  both  motor-control  and  command-read  correspond  to  their  interrupt 
routines  and  execute  at  high  priorities.  Synchronization  accounts  for  the  other  components.  For  example,  the  last 
component  of  command-process  updates  control  variables  that  will  be  used  by  other  tasks.  Interference  from 
other  tasks  is  avoided  by  accessing  those  variables  at  a  high  priority  level.  The  other  components  have  been  created 
to  reflect  the  synchronization  pattern  between  processes  sharing  data  (in  this  case  between  sensor-read  and 
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sensor_control),  and  between  command-read  and  command-process.  Priority  inheritance  protocols 
have  been  used  to  avoid  priority  inversion  [12].  These  protocols  change  the  priority  of  the  tasks  at  synchronization 
points,  thus  dividing  the  tasks  into  components. 


Task 

Period 

Exec,  times 

Deadline 

Priorities 

Cl 

C2 

C3 

Pi 

Pi 

Pi 

Motor  control 

40 

1 

5 

- 

40 

10 

7 

- 

Sensor  read 

100 

10 

5 

5 

100 

4 

8 

4 

Sensor  control 

50 

8 

12 

- 

50 

5 

8 

- 

Command  read 

200 

10 

20 

3 

200 

9 

2 

3 

Command  process 

400 

2 

12 

10 

400 

3 

1 

6 

Table  1 :  Timing  requirements  for  the  task  set 


The  Analysis  of  the  Robotics  System 

We  have  determined  the  schedulability  of  the  task  set  by  computing  the  minimum  and  maximum  response 
times  for  each  task.  This  technique  has  enabled  us  to  evaluate  performance,  identify  inefficiencies,  and  suggest 
optimizations  to  the  architecture.  Using  the  same  algorithms  we  have  analyzed  the  modified  design,  and  then 
evaluated  the  effects  of  our  changes. 

Computing  response  times  for  all  processes  generated  the  results  in  table  2.  This  table  shows  that  the  task  set  is 
schedulable.  Moreover,  the  maximum  execution  times  of  many  tasks  are  close  to  their  deadlines.  This  indicates  a 
high  load  on  the  system;  it  is  unlikely  that  adding  more  tasks  to  the  task  set  would  produce  a  schedulable  system. 
This  information  allows  the  designer  to  optimize  or  fine  tune  the  system. 


Task 

Deadline 

Exec,  times 

min 

max 

Motor  control 

40 

6 

16 

Sensor  read 

100 

45 

95 

Sensor  control 

50 

20 

49 

Command  read 

200 

181 

190 

Command  process 

400 

219 

223 

Table  2:  Schedulability  analysis  for  original  system 


Using  the  results  computed  by  our  algorithms,  we  have  been  able  to  suggest  changes  to  the  design  and 
to  analyze  the  effects  of  such  changes.  In  the  original  design  sensor-read  generates  data  that  is  used 
by  sensor-control.  However,  the  two  tasks  execute  independently  of  one  another.  In  some  cases 
sensor-control  might  execute  even  if  data  is  not  yet  available.  In  this  case,  sensor-control  uses  data 
generated  by  the  previous  instantiation  of  sensor-read,  which  may  be  obsolete.  We  have  changed  the  system 
to  avoid  this  problem  and  have  analyzed  the  resulting  design.  The  modification  consists  of  making  the  termination 
of  sensor-read  trigger  the  execution  of  sensor-control.  Care  must  be  taken,  however,  because  the  pro¬ 
cesses  involved  have  different  periods;  sensor-read  executes  every  100ms,  while  sensor-control  exe¬ 
cutes  every  50ms.  We  change  the  system  so  that  sensor-read  signals  the  execution  of  sensor-control 
every  100ms, but  sensor-control  alsoexecutesindependentlySOmsafter  sensor-readruns.  Inthiscase 


one  instantiation  of  sensor_control  is  synchronized  with  sensor_read  while  the  other  is  independent. 
The  schedulahility  analysis  of  the  modified  example  is  given  in  table  3 : 


Task 

Deadline 

Exec,  times 

min 

max 

Motor  control 

40 

6 

16 

Sensor  read 

100 

20 

36 

Sensor  control 

50 

21 

121 

Command  read 

200 

91 

91 

Command  process 

400 

96 

296 

Table  3:  Schedulahility  analysis  for  modified  system 


The  new  design  is  not  schedulable,  since  sensor_control  can  take  up  to  121ms  to  execute.  We  can  use 
the  same  quantitative  algorithms  to  find  out  more  about  the  behavior  of  the  system  and  to  correct  the  problem.  A 
more  detailed  analysis  reveals  that  the  two  instantiations  of  sensor_control  have  very  distinct  behaviors. 
Whenever  executing  periodically  (and  independent  of  sensor_read),  sensor_control  takes  between  21 
and  121ms  to  finish.  However,  whenever  executing  after  sensor_read,  it  takes  exactly  26ms  to  execute  in  the 
modified  model.  This  shows  that  the  periodic  execution  of  sensor_control  is  the  bottleneck  of  the  system. 
One  solution  to  the  problem  is  simply  removing  the  periodic  instantiation  of  sensor_control.  This  solution 
was  easily  implemented,  and  the  schedulahility  analysis  is  presented  in  table  4: 


Task 

Deadline 

Exec,  times 

min 

max 

Motor  control 

40 

6 

16 

Sensor  read 

100 

20 

36 

Sensor  control 

50 

26 

26 

Command  read 

200 

91 

91 

Command  process 

400 

70 

270 

Table  4:  Schedulahility  analysis  for  final  system 


The  system  is  again  schedulable,  but  now  sensor_control  executes  only  once  every  100ms.  Is  this  a 
satisfactory  solution?  Again,  we  can  use  the  same  algorithms  to  analyze  the  modified  design.  By  computing 
the  time  between  the  end  of  the  execution  of  sensor_read  and  the  beginning  of  sensor_control  we 
can  verify  if  data  produced  by  the  first  task  is  being  consumed  timely  by  the  second  one.  In  the  modified 
model  this  time  is  between  1  and  7ms,  meaning  that  data  produced  by  sensor_read  is  promptly  consumed  by 
sensor_control.  Therefore  we  can  conclude  that  in  spite  of  changing  the  periodicity  of  sensor_control 
we  are  still  maintaining  predictability.  The  condition  counting  algorithms  have  also  been  useful  in  analyzing 
the  performance  of  this  model.  We  have  been  able  to  verify  how  the  old  periodicity  of  sensor_control 
relates  to  the  new  model.  We  can  consider  all  execution  paths  from  the  time  sensor_read  starts  until 
sensor_control  finishes  as  the  active  period  for  the  measurement  subsystem.  During  such  a  period,  how 
many  times  can  the  50ms  timeout  occur?  In  other  words,  how  many  times  would  sensor_control  be 
activated  using  the  original  periodicity  during  an  active  period?  The  result  is  from  1  to  3  times.  We  conclude 
that  the  modified  system  satisfies  the  original  timing  constraints,  even  though  it  has  a  lighter  load. 
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In  this  example  we  were  able  analyze  the  behavior  of  the  robot  from  several  perspectives.  We  have  determined 
that  it  would  meet  its  deadlines,  but  that  it  was  inefficient.  We  were  able  to  optimize  the  design  and  analyze  the 
performance  of  the  modified  design.  The  example  shows  that  these  techniques  are  both  easy  to  use  and  versatile 
enough  to  be  of  great  assistance  in  specifying  and  verifying  real-time  systems. 

6  Conclusion 

This  paper  describes  a  tool  for  computing  quantitative  properties  of  real-time  systems.  A  formal  state-transition 
graph  model  of  the  system  is  constructed  from  a  description  written  in  the  Verus  language.  We  show  how  this 
graph  can  be  used  to  determine  the  minimum  and  maximum  delay  between  two  events  and  how  to  compute  the 
minimum  and  maximum  number  of  times  a  given  event  can  occur  on  any  path  between  two  state  sets. 

Because  our  techniques  are  based  on  symbolic  model  checking,  they  can  be  applied  to  designs  of  realistic 
size  and  complexity.  Frequently  it  is  possible  to  search  exhaustively  state  spaces  with  10^*^  states  in  a  matter  of 
minutes.  We  demonstrate  the  power  of  these  techniques  by  analyzing  a  complex  robotics  system  and  showing  that 
its  timing  requirements  are  satisfied.  In  addifion,  our  approach  provides  the  user  with  quantitative  information 
rather  than  simply  verifying  that  a  formula  is  true  in  the  model.  In  other  words,  our  algorithms  can  compute 
performance  measures  in  addition  to  verifying  correctness.  Our  techniques  can  also  be  used  during  the  design 
process  itself.  In  the  robot  controller  example  we  have  shown  how  the  information  generated  by  our  algorithms 
can  be  used  to  suggest  optimizations  to  the  system.  These  modifications  can  again  be  analyzed  to  see  how  the 
system  behavior  has  changed. 

There  are  a  number  of  possibilities  for  extending  the  range  of  problems  that  can  be  handled  by  our  techniques. 
In  the  future  we  intend  to  augment  the  model  to  allow  transitions  to  be  labelled  with  probabilities.  Statistics 
about  different  paths  in  the  graph  can  then  be  generated.  In  some  cases,  we  only  want  paths  satisfying  certain 
properties  to  be  considered  by  our  algorithms.  Linear  temporal  logic  formulas  seem  to  be  ideal  for  restricting 
the  set  of  paths  considered.  It  is  clear  that  these  extensions  would  make  our  approach  more  powerful  and  would 
allow  us  to  handle  an  even  larger  class  of  systems. 
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